跳到主要内容

流式渲染（Streaming SSR）与 SSR

流式渲染（Streaming SSR）与传统 SSR 本质同属于服务端渲染范畴，但在数据传输机制、用户体验、架构能力上存在差异。 React 18+ 的流式能力更是将 SSR 从“整页生成”推进到“组件级渐进交付”的新阶段。

一、与普通 SSR 对比​

1. 渲染与传输​

  • 普通 SSR： 同步生成完整 HTML ➞ 全部生成后一次性发送
  • 流式渲染： 异步分快生成 ➞ 生成即发送，流式渲染荣国 Node.js stream/ Web Readable Stream 发送生成的块

2. 首屏感知速度​

  • 普通 SSR： 用户需等待整页生成（TTFB 高，白屏时间长）
  • 流式渲染： 首屏关键内容（如导航栏）可秒极呈现，用户“感觉更快”

3. API（React）​

  • 普通 SSR： renderToString （React 18+ 已标记为 legacy）
  • 流式渲染： renderToPipeableStream （Node）、 renderToReadableStream（Edge/Web）

4. Suspense 集成​

  • 普通 SSR： ❌ 不支持（任一组件卡顿即阻塞整页）
  • 流式渲染： ✅ 原生支持： 配合 <Suspense> 实现 “占位 ➞ 独立流式填充”，如 ： <Suspense fallback={<Spinner />}><Comments /></Suspense>

5. 水合(Hydration)​

  • 普通 SSR： 客户端需等待整页 HTML + JS 加载后统一水合
  • 流式渲染： React 18+ 支持渐进式水合：已接收区块可独立交互，提升响应速度

6. 资源与错误​

  • 普通 SSR： 大页面易内存峰值；错误导致整页失败
  • 流式渲染 内存压力小；单区块错误可隔离（配合错误边界）

7. 使用场景​

  • 普通 SSR： 内存简单、无延迟数据、对首屏速度要求低
  • 流式渲染： 内容复杂、含第三方 API （评论/推荐） 、需 SEO + 快速首屏、部署于 Edge

二、本质联系​

  • 同属 SSR 范式： 均由服务端生成初始 CSR 首屏空白与 SEO 问题
  • 水合是共同点： 最终均需客户端 JS 激活交互（流式仅优化了 “等待水合” 的体验）
  • 流式是 SSR 的演进 ： 传统 SSR 可视为“单 chunk 流式”，流式渲染是其能力扩展而非代替
  • 框架统一抽象： Next.js 等通过 getServerSideProps/generateStaticParams 屏蔽底层差异，开发者按需选择

三、React 18+ 的关键突破：组件级流式​

流式渲染的真正革命在于 与 Suspense 深度结合：

<Suspense fallback={<div>加载评论。。。</div>}>
  <Comments /> {/*  可能调用慢速的第三方 API */}
</Suspense>
  • 关键内容优先： 用户先看到导航、主页，而非整个页面卡住
  • 网络并行化：浏览器提前解析已接收 HTML，预加载 CSS/JS
  • 架构解耦：慢组件不影响快组件的交付节奏
流式 ≠ 自动更快

若首屏内容依赖慢借口且无 Suspense 拆分，流式优势无法展现。需结合内容分层设计（Critical CSS、资源预加载）发挥最大价值

最后于 更新